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Problem Statement 


e Poor interoperability of Blockchain & DLT systems 


¢ Transfers of virtual assets must be mediated by 3" 
party entities (e.g. crypto-exchanges) 


e Centralization (choke point) 
e Lack of system autonomy & limited scalability 
e Asset lock-in 


Problem Statement 
e Transfers mediated by Third Party (Exchange) 


Exchange 
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Proposed Solution: Gateway-to-Gateway Protocol 


e Standardized protocol 
e Agnostic to economic value 
e Stands in front of DLT system 





3 


Gateway 
Protocol 











SecDispatch WG IETF109 


Gateway-to-Gateway Protocol 


Application 


Scope of IETF work 








| Ledgerlt | Ledgerlt 


(Resources) 


Gateway | LedgerL2 er L2 
E | LedgerL2 


(Resources) 


Gateway 
l Protocol l 
DLT System | (Open Digital Asset DLT System 
(Origin) | Protocol) ! (Destination) 


Gateway-to-Gateway Protocol 


e Protocol between gateways to securely transfer 
the digital reoresentation of an asset, 


e unidirectional, 


satisfying requirements of atomicity and non- 
repudiation, 


agnostic to the higher-layer economic value of 
the asset 


Proposed Scope of Work 


e Gateway API definitions (RESTful APIs) 

e Resource identifiers 

e Payload definition 

e Message flows and commands 

e Secure channel establishment (e.g. TLS1.3) 
e Terminology (extending NISTR-8202) 


Out of Scope 


e Blockchains and DLT systems 

e Consensus & BFT protocols, POW, Pos, etc. 
e Cryptocurrencies, tokenization, etc. 

e Incentive mechanisms, economic models; etc. 
e Zero-knowledge proof (ZKP) protocols 

e Authentication & Authorization protocols 
e Concurrency control algorithms 

e Identity management & privacy, etc. etc. 


Gateway Protocol: Desirable Features 


e Must work if one (or both) DLTs are private — 
interior resources externally inaccessible 


e Must work if one side is a Legacy system 


e Must result in atomic settlement with sufficient 
evidence (in case of disputes) 


e Support for different client modes for resource 
access (see ODAP draft) 


Gateway Protocol: General Transfer Requirements 


e Atomicity: Transfer must either commit or entirely fail 
(failure means no change to asset ownership) 


e Consistency: Transfer (commit or fail) always results in 
asset located in one DLT only 


¢ Isolation: While transfer occurring, asset ownership 
cannot be modified (no double-spend) 


e Durability: Once transaction committed, must remain 
so regardless of gateway crashes 


Proposed Deliverables 


e Architecture specification 
e Protocol specification (ODAP) 
e Use-cases & Requirements 


e Optional 
e Asset Profile JSON specification 
e Log-metadata JSON specification (crash recovery) 


Proposed Roadmap & Timeline 


e November IETF109: 
e SecDispath Presentation & call for participation 


e March IETF110: BOF request for WG creation 
e Nov 2021 (or earlier): Drafts completed (WG LC) 
e Close-down WG or Recharter 


www.ietf.org/mailman/listinfo/blockchain-interop 


Why the IETF 


e Neutrality 
e History of gateway protocols (e.g. BGP4, IPsec/IKE) 
e Expertise in security protocols 


e Home of: TCP/IP, HTTP, IPsec, IKE, Kerberos, TLS, 
OAuth2.0, JWT, JWE, CoAP, RATS, etc. 


e Existing liaisons (e.g. ITU, W3C, 3GPP, etc.) 


Call for Participation 


www.ietf.org/mailman/listinfo/blockchain-interop 


